This, to me, is a whole new feature added to the Image class -- and one that I've wanted for a while! Thanks! It's good that it updates the internal editor screenshot functionality, but I think it would be great to consider adding this as a new feature of the Image class in 4.8. #119013 can still be merged as the basic bugfix for 4.7.

Haven't tested this yet, but sometime before this is ready for review, docs will need to be updated in at least these three spots:

1. https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-srgb-to-linear
2. https://docs.godotengine.org/en/stable/classes/class_image.html#class-image-method-linear-to-srgb
3. https://docs.godotengine.org/en/stable/classes/class_viewporttexture.html#description
   • The order of the two lines in the example script needs to be changed, just like the changes made to editor_node

Here is a list of other places that call these updated functions that might benefit from reworking in the same way as EditorNode:

1. texture_loader_ktx.cpp: static Ref<Image> load_from_file_access(Ref<FileAccess> f, Error *r_error)
2. image_loader_svg.cpp: ImageLoaderSVG::load_image(Ref<Image> p_image, Ref<FileAccess> p_fileaccess, BitField<ImageFormatLoader::LoaderFlags> p_flags, float p_scale)
3. scene_debugger.cpp: SceneDebugger::_msg_rq_screenshot(const Array &p_args)
4. movie_writer.cpp: MovieWriter::add_frame()

Here is a list of other places that call these updated functions that might benefit from reworking in the same way as EditorNode:

Seems like 1 and 2 does not work with any half-float formats, so won't be affected or need any changes, 3 is already changed to do convention to RGBA8 after linear-to-srgb, added the same for the 4.

docs will need to be updated in at least these three spots

Updated.

For the reference current half-float code is about 10 times slower than RGBA8 lookup table code, it's still acceptable for screenshots (takes about 0.5 sec for 8K image in debug build), but likely is not OK for MoveWriter.

Edit: if parallelized, it's slightly faster than RGBA8, but offloading it to GPU would likely be a better option.

It’s good to hear there are options for making movie maker faster. It should, like most parts of the engine, be as fast as possible.

That said, even if movie maker ends up being significantly slower when the window’s HDR 2D setting is enabled I think the improved visual quality is what most users would desire for this feature. My reasoning is:

1. Users primarily use the movie maker feature for lossless and high quality frame-by-frame capture.
2. When users are not concerned about visual quality, they use an external capture tool like OBS, which is very high performance at the cost of some visual quality.
3. I believe movie maker can simply slow down game output while running to make sure no frames are dropped.

In short, if users want highest quality, they use the Movie Maker feature in Godot. If they want highest performance and do not need lossless quality, they use something like OBS instead.

That’s my guess, anyway…

Movie Maker is mostly about getting perfect frame pacing and using graphics settings not viable in real-time. You can get lossless quality from OBS, but it's way more likely to drop frames (even on a top-end system).